Skip to content

Offer the Acquia trial signup when the account has no applications - #1

Open
lauriii wants to merge 3 commits into
acli-createfrom
acli-trials
Open

Offer the Acquia trial signup when the account has no applications#1
lauriii wants to merge 3 commits into
acli-createfrom
acli-trials

Conversation

@lauriii

@lauriii lauriii commented Aug 5, 2026

Copy link
Copy Markdown
Owner

Note

Stacked PR: this branch is based on acli-create and depends on acquia#2033. The diff shows only the trial-provisioning capability.

Why

acli dev:init (acquia#2033, formerly acli setup) dead-ends for a genuine newcomer: it authenticates and then asks the user to pick an existing application, but a brand-new account has nothing to pick. This PR closes that gap so the one-liner is honest for someone starting from zero.

How applications get created

The public Cloud Platform API is read-only for applications and subscriptions (OPTIONS /api/applications returns allow: GET). Trials are created through the trials service (trials-service-prod.prod.mesh.cicd.acquia.io), which accepts the same OAuth client_credentials tokens as the Cloud API — verified live. Its path prefixes are inconsistent by design and encoded carefully: POST /trials (create) and POST /api/trials/{id} (retry) vs GET /api/trials (current trial, 404 = none) and GET /api/trials/{id} (status poll).

What this adds

acli trials:create (alias trial:create) — the small CLI wrapper + polling loop:

  • --site-name, --template (validated against the catalog: archimedes, byte, caresphere, convene, convivial_gov, drupal_cms_starter, haven, healthcare, local, provus_edu, pulse — hard-coded with a @todo, the service has no catalog endpoint yet), --region. All defaulted, so it works non-interactively.
  • Safe to re-run: an existing trial is reported (COMPLETED), resumed (in progress), or retried (failed) instead of erroring.
  • Honest progress: percent_complete + status printed as they change, a note every minute, timeout after 30 minutes (ACLI_TRIAL_TIMEOUT overrides, validated numeric) with exact resume instructions, and the service's failure_reason surfaced verbatim on failure.

acli dev:init integration — the trial path is reachable three ways, not gated on having existing applications or sites:

  • Zero applications: dev:init explains the trial and offers to create one (with a confirm).
  • The application picker: every interactive run's list ends with "Create a new application (free 14-day Acquia trial)".
  • --new: skips straight to trial creation; works non-interactively.

After trials:create succeeds, dev:init polls GET /applications until the new application appears, waits for a non-production environment with a git URL, and continues the existing flow to a running local site. Re-running acli dev:init resumes naturally at every stage. Zero-apps non-interactive runs do not create a trial implicitly; they fail fast pointing at acli dev:init --new / acli trials:create.

Implementation notes

  • CommandBase: pollCloud() (shared backoff poll with testable timeout), and promptChooseEnvironmentConsiderProd() / promptChooseApplication() widened privateprotected (one word each) so DevInitCommand reuses the standard choosers; base behavior for other commands is unchanged.
  • The trials service token is fetched via the same client_credentials grant the SDK uses, and refreshed once automatically on a 401 mid-poll (provisioning outlives the ~5-minute token lifetime).
  • The Salesforce lead endpoint (POST /trials/account, fire-and-forget CRM record) is not called; add later if wanted for parity with the UI.

Verification — live, against the real trials service

Run for real with limited agent credentials (lauri.timmanee+agent@acquia.com):

  • Created a real trial: POST /trials → trial 422ba415-dbc8-4830-bd10-1f80a8ce6dfc, then polled its status for the full 15 minutes of server-side provisioning.
  • The trial failed server-sideno subscription unit is available for region "us-east-1" (the prod trial pool was empty at test time) — and the command surfaced that reason verbatim with retry guidance.
  • Retry verified live: re-running found the failed trial, POST /api/trials/{id} reset it to INITIATED (7% → 14% progress output), and the ACLI_TRIAL_TIMEOUT override + timeout messaging worked.
  • Auth (404-not-401 semantics), status polling, and progress output all exercised for real.

Not verified live: a trial reaching COMPLETED (blocked by the empty pool, not by the CLI — the full status object shape including site_url comes from the service's own responses and the Cloud UI fixtures), and therefore the post-trial dev:init continuation against a real new application. Those legs are covered by spec-fixture/mocked tests (TrialsCreateCommandTest, DevInitCommandTest) including the zero-applications, picker, --new, decline, failure, retry, 401-refresh, and timeout paths. A human can finish verification by re-running acli trials:create once the trial pool has capacity, then acli dev:init.

Leftover state from testing: the failed trial above remains on the agent account (no subscription was created; re-running trials:create retries it). The eelaurieskola application was never touched.

Repo checks: phplint, phpcs, phpstan, and the full PHPUnit suite (65 serial + 561 parallel) pass locally.

🤖 Generated with Claude Code

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR enhances acli setup to handle first-time Acquia Cloud users who authenticate successfully but have zero existing applications, by offering a browser hand-off to the Acquia trial signup and then resuming setup once a new application (and a cloneable environment) appears via the Cloud API.

Changes:

  • Add a --new flag and a trial-signup + polling flow to create/await a new application when none exist (or when explicitly requested).
  • Wait for trial environment provisioning (non-production, non-node, with a git URL) before continuing into the existing setup workflow.
  • Expand PHPUnit coverage for the zero-applications path, non-interactive failure modes, and timeout behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
tests/phpunit/src/Commands/App/SetupCommandTest.php Adds tests for the new trial-signup flow, non-interactive failures, and timeout handling.
src/Command/CommandBase.php Widens environment-chooser helper visibility to support reuse from the new setup path.
src/Command/App/SetupCommand.php Implements trial-signup prompting, polling/backoff logic, and environment provisioning waits; adds --new.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/Command/App/SetupCommand.php Outdated
@lauriii lauriii added the enhancement New feature or request label Aug 5, 2026
Add `acli trials:create`: creates a free 14-day trial through the trials
service (POST /trials, polled at GET /api/trials/{id} with percent
progress), resumes an in-flight trial, retries a failed one, and reports
an existing one — always safe to re-run. The template catalog is
hard-coded until the service exposes one.

dev:init uses it so a developer with no application never dead-ends: the
zero-application path offers a trial, the application picker gains a
"Create a new application" choice, and --new skips straight to trial
creation. After the trial completes, dev:init waits for the new
application and a cloneable environment, then continues to a local site
with the usual resumability.

Verified live against the production trials service: created a real
trial, watched provisioning, and exercised the retry and timeout paths.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
lauriii and others added 2 commits August 6, 2026 03:25
Assert the token grant, Bearer headers on both sides of a 401 refresh,
and http_errors in the request matchers; cover all three error-message
fallback arms and the HTTP 400 boundary; and assert the dev:start help
paragraph's position.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… cast

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants